fix: Queued-agent polling repeatedly loads and transfers full growing run output - #1089

What changed

• Added a summary projection to GET /v2/runs/{id} using the existing output-free run columns and scanner.
• Changed both queued-agent wait paths to poll summary responses only.
• Fetches the full run exactly once after a terminal summary is observed, preserving the final response/stdout/error metadata returned by wait_for_jobs.
• Added coverage for job-ID and run-ID polling with a 1 MiB output payload, plus server coverage that by-ID summaries omit stdout, stderr, thinking, and response.

Why this is high-value

Jarvis uses queued agents and jobs routinely, and wait_for_jobs polls every five seconds. Previously every poll selected growing SQLite TEXT output fields, encoded them into JSON, transferred them, read the full body, and decoded it just to inspect status. For a run with 1 MiB of accumulated output polled 100 times, that means roughly 100 MiB of avoidable transfer and decoding.

After this change, polling cost is bounded by the small status/metadata projection; large output is read, encoded, transferred, and decoded only once at completion. This reduces SQLite reads, JSON CPU, network traffic, and transient allocations without changing the final tool result.

Validation

• gofmt -w cmd/serve_jobs_v2.go cmd/serve_jobs_v2_test.go internal/tools/queue_agent.go internal/tools/queue_agent_test.go
• go test ./internal/tools -run '^TestWaitForJobs' -count=1
• go test ./cmd -run '^TestJobsV2RunsSummaryOmitsOutputPayload$' -count=1
• go build ./...
• Isolated-home go test ./...: all packages passed except the pre-existing internal/serveui TestProductionBundleSizeBudgets failure (app.js 427861 bytes vs 426000-byte raw budget). The same failure is present on upstream df774423 CI: https://github.com/SamSaffron/term-llm/actions/runs/33309849469
• git diff --check